REMARKS 

1 . Applicants have amended the first paragraph of this apphcation in accordance 
with the suggestions of the Examiner on page 3 of the Office Action dated 02/28/2006, to fulfill 
the requirements of 35 U.S.C. 120 and 37 C.F.R. 1.78. 

2. Applicants have revised the claims in accordance with the suggestions of the 
Examiner. Applicants have also revised the claims to make the claims definite and to eliminate 
inconsistencies that applicants* attorney noted in the claims in preparing this amendment. As 
now written, the claims are believed to be definite. 

3. The Examiner has cited as a separate reference, against a number of the claims 
including claims 6, 7, 8, 9, 10-12, 24, 25, 39 and 40-42, the Altman et al. pending apphcation 
US2003/8 120526 filed on October 16, 2002. Altman has a filing date of 10/16/2002. This is 
after applicants* filing date. 

Altman filed provisional application 60/329,281 on October 16, 2001 in the 
USPTO. Applicants are enclosing a copy of the Altman provisional application. As the 
Examiner will note, the Altman provisional application does not provide a sufficient number of 
drawings or a sufficient specification to support the Altman non-provisional application. For 
example, there are at least ten (10) figures showing circuit diagrams and flow charts in the 
Altman non-provisional application. There are no circuit diagrams or flow charts in the Altman 
provisional application. 

37 CFR 1.53(c) reads as follows: 

''Application filing requirements - Provisional application. 
The filing date of a provisional application is the date on which a 
specification as prescribed by the first paragraph of 35 U.S.C, 112, and 
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any drawing required by §1.8 1(a) are filed in the Patent and Trademark 
Office. No amendment, other than to make the provisional application 
comply with the patent statute and all applicable regulations, may be 
made to the provisional application after the filing date of the provisional 
application. " 

In accordance with the provisions of 37 CFR 1.53(c), the Altman provisional application has no 
effect in establishing a filing date of the Altman non-provisional application since Altman filed 
the non-provisional appUcation after 12/2/01, the fiUng date of this application. Because of this, 
the Examiner should withdraw the Altman non-provisional patent application as a prior art 
reference and should allow claims 6, 7, 8, 9, 10-12, 24, 25 and 40-42 over the other references 
cited by the Examiner. 

4. Claims 26-29, 31, 33, 34 and 36 have been rejected under 35 U.S.C. 103(a) as 
being unpatentable over Iyengar patent 6,360,205. Claims 26-29, 31, 33, 34 and 36 are 
allowable over Iyengar for the following reasons, 
a. Claim 26 

In claim 26, applicants recite that the legacy transactions are performed 
simultaneously with the individual transactions and that the legacy transactions and the 
individual transactions are provided simultaneously. Applicants also recite that the legacy 
transactions and the individual transactions are displayed simultaneously on different portions of 
a display screen. Iyengar does not disclose this. Contrary to the position of the Examiner, 
Iyengar does not disclose, in (a) column 7, lines 48-60, (b) column 9, lines 40-43, (c) colunan 11, 
lines 30-34 and (d) column 16, lines 4-7, the steps of providing prices for the transactions at a 
processing station from a plurality of first sources at published prices for the transactions, and 
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providing for the transmission of the prices discounted from the estabhshed prices from the first 
sources to the processing station. Iyengar also doesn't disclose in column 16, lines 4-17 that the 
searches for the published and the discounted fares are performed simultaneously. There is also 
no disclosure by Iyengar in column 11, lines 30-35 that the published prices and the discounted 
prices are displayed simultaneously on a display screen. Because of the failure of Iyengar to 
disclose the features discussed above, claim 26 is allowable over Iyengar. 

b. Claim 27 

Claim 27 is dependent from allowable claim 26. Furthermore, Iyengar 
does not disclose, in (a) column 1, lines 56-61, (b) colunin 7, lines 49-61 (c) column 8, lines 6-9, 
(d) column 11, lines 30-55, (e) column 16, Hnes 4-17 and (f) column 3, lines 10-14, that the 
published prices for the transactions are provided in a first protocol, that the discounted prices for 
the transactions and the prices from other sources are provided in a second protocol and the first 
and second protocols are made compatible and that the published prices and the discounted 
prices in the compatible protocol are displayed simultaneously on the display server. 

c. Claim 28 

Claim 28 is dependent from allowable claim 26. Iyengar 
additionally does not disclose, in (a) column 6, lines 60-65, (b) column 7, lines 49-61, (c) 
column 8, lines 6-9, (d) column 16, lines 4-17 and (e) column 3, lines 10-14, the steps of 
providing prices for the transactions at the processing station from at least one second 
source offering published prices for the second source, the second source being different 
from the first source, providing for the transmission of the published prices from the at 
least one second source to the processing station and displaying the published prices from 
the at least one second source on the display server simultaneously with the display of the 
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published and discounted prices from the first source and the other sources and from the 
at least one second source in the display server simultaneously with the display of the 
published and discounted prices from the first source and the other sources. Because of 
this, claim 28 is allowable over Iyengar. 

d. Claim 29 

Claim 29 is dependent from allowable claim 28. Claim 29 is also 
allowable over Iyengar because of. the recitations in claim 29. For example, Iyengar does 
not disclose that the published prices from the at least one second source is provided with 
a protocol different from the first and second protocols, that the fares from the first and 
second sources are searched simultaneously and that the fares are displayed 
simultaneously. 

e. Claim 3 1 

In analyzing claim 3 1, the Examiner has referred to Altman. 
Applicants are analyzing the Examiner's interpretation of the claim on the basis that the 
Examiner intended to refer to Iyengar. 

The Examiner has not cited portions of Iyengar against claim 3 1 . 
However, Examiner does not disclose any of the steps recited in claim 31. 
f Claim 32 

Claim 32 is dependent from allowable claim 3 1 . furthermore, the 
Examiner has admitted that Iyengar does not disclose the steps of providing a printer at 
the legacy server and printing, in the printer at the legacy server, a ticket providing for the 
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perfomiance of the selected one of the legacy and individual transactions as the particular 
transaction. 

The Examiner has indicated in column 14, lines 5-11, that a 
confirmation is sent to the legacy server and that the legacy system mails the customer a 
ticket. Therefore, according to the Examiner, it would have been obvious to one of 
ordinary skill in the art at the time of the invention to modify the invention of Iyengar to 
include printing the ticket at the legacy server so that the ticket is automatic. However, 
Iyengar does not disclose that the legacy server prints the ticket and furthermore that the 
legacy server prints the ticket at the time of the selection of the legacy. 

g. Applicants have added claim 43 in this amendment as dependent 
from allowable claim 42. Claim 43 is allowable over Iyengar because Iyengar does not 
disclose the step of simultaneously printing in the printer at the legacy server, the cost of 
the ticket providing for the selected one of the legacy and individual transactions as the 
particular transaction. 

h. Claim 33 

Claim 33 is dependent from allowable claim 31. 

i. Claim 34 

Claim 34 is allowable over Iyengar because it is dependent from 
allowable claim 31. Furthermore, column 6, lines 13-20 in Iyengar does not disclose that 
the indications of the legacy transactions are provided to the database at the processing 
station through a wide area network. 
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j. Claim 35 

The Examiner has apparently cited the combination of Iyengar and 
Gerra against claim 35. Claim 35 is dependent from claim 33 and is accordingly 
allowable over the combination of Iyengar and Gerra for the same reasons as claim 33. 
This has been discussed previously in these remarks, 
k. Claim 36 

Claim 36 is dependent from allowable claim 35. Claim 36 is also 
allowable over Iyengar for the same reasons as claim 34. 

Claim 36 has been rejected under 35 U.S.C. 109(a) as being 
unpatentable over Iyengar in view of Gerra. Claim 36 is allowable over the combination 
of references for certain important reasons. 

For example, the Examiner has admitted that Iyengar does not 
disclose prices on the first and second portions of the display screen. The Examiner has 
cited Gerra in column 2, lines 62-67 and Gerra , column 2, lines 30-40. Column 2, lines 
20-30 in Gerra is in the Background of the Invention. Gerra indicates a need rather than 
an accomplishment. Column 2, lines 62-67 in Gerra is in the Summary of the Invention. 
It does not indicate that the published prices from the first sources and the published 
prices from the at least one second' source are in incompatible formats and these 
published prices are displayed in a compatible format. For the reasons specified above, 
claim 36 is allowable over the combination of Iyengar and Gerra. 

5. The Examiner has cited other references than Iyengar against a number of 
the claims including; 
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a. Claim 37 

Claim 37 has been rejected under 35 U.S.C. (4) as being 
unpatentable over Iyengar in view of Gardiner patent application 052002/017034. Since 
claim 37 is dependent from allowable claim 34, claim 37 is allowable over the prior art 
for the same reasons as claim 34, 

The Examiner has admitted that Iyengar does not disclose the steps 
of providing an accounting application at the legacy server and operating the accounting 
application at the legacy server to provide an accounting record of the selected one of the 
legacy and the individual transactions as the particular transaction and to provide an 
accounting record of the price of the selected one of the transactions. Gardiner also does 
not disclose this information in paragraphs 0007, 0039, 0045 and 0053. Because of this, 
claim 37 is allowable over the combination of Iyengar and Gardiner. 

b. Claim 38 

Claim 38 has been rejected under 35 U.S.C. 103(a) as being 
unpatentable over Chen pending application US 2002/0152100. Actually, claim 38 has 
been rejected over a combination of Chen and Altman. (See the last two(2) sentences on 
page 21 of the Office Action concerning Altman.) Since Altman is not a good prior art 
reference for the reasons discussed above, Chen 38 is allowable over Chen when only 
Chen is used as a prior art reference. 

Furthermore, contrary to the position of the Examiner, Chen does 
not disclose in paragraphs 0028 and 0036 the steps of providing legacy transactions and 
individual transactions and providing a local area network and a printer at the processing 
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station. Chen also does not disclose in paragraphs 0061-0065 the steps of providing at 
the processing station a database for storing volatile information including a selected one 
of the legacy transactions and the individual transactions, and the price of the selected 
one of the legacy transactions and the individual transactions, as the particular 
transaction. There is also no disclosure in Chen of the step of providing for the passage 
through the internet to the printer of the selected one of the legacy transactions and the 
individual transactions as the particular transaction and the cost of the selected one of the 
legacy transactions and the individual transactions. There is also no disclosure in 
paragraph 0032 of Chen of the step of printing at the printer the selected one of the 
legacy transactions and the individual transaction. According to the Examiner, Chen has 
admitted that Chen does not disclose the printing of the selected transaction. 

For the reasons discussed above, claim 38 is allowable over Chen and the 
combination of Chen and Pitman. 

c. Claim 39 

Since claim 39 is dependent from allowable claim 38, it is allowable 
over Chen, and the combination of Chen and Altman, for the same reasons as claim 38. 
Altman, in paragraphs 35 and 50-59, and Gerra additionally do not disclose that the 
legacy transactions, and the price of the legacy transactions, are transmitted to the 
processing station through a wide area network and that the individual transactions and 
the price of the individual transactions are transmitted to the processing station through 
the internet. Altman is also not a proper reference for the reasons discussed above. 
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d. Claims 40-42 

Claims 40-42 have been rejected under 33 U.S.C. 103(a) as being 
unpatentable over Chen in view of Gerra in view of Altman. Claims 40-42 are allowable 
over the combination of Chen and Gerra since Altman is not a proper reference for the 
reasons discussed above. 

e. Claim 40 • 

Gerra does not disclose in (a) column 7, lines 1-25 and column 8, 
lines 4-7 that the legacy transactions are provided in a first protocol, the individual 
transactions are provided in a second protocol different from the first protocol and the 
first and second protocols are made compatible at the processing station. Paragraph 0059 
in Altman, additionally provides a general discussion that does not disclose what is 
specifically recited in claim 40. Furthermore, Altman is not a proper reference for the 
reasons discussed above. 

f. Claim 41 

Claim 41 is dependent fi:om allowable claim 40. 

g. Claim 42 

Claim 42 is allowable over the references for the same reasons as 
claim 40 because it is dependent from allowable claim 40. 

6. A number of the claims are allowable over the references because Altman 
is not a proper reference. The other claims are allowable over the cited references 
because they recite features not disclosed in the cited references. 
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Reconsideration and allowance of the application are respectfully requested. 



Respectfully submitted, 
FULWIDER P ATTON LLP 



Ellsworth R. Roston 
Registration No. 16,310 



Howard Hughes Center 
6060 Center Drive, Tenth Floor 
Los Angeles, CA 90045 
Telephone: (310) 824-5555 
Facsimile: (310)824-9696 
Customer No. 24201 
ERR:dmc 

Enclosure: (Copy of the Altman provisional apphcation 60/329,281 filed 10/16/2001) 
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Graphical Travel Wizard 

Graphical Travel Wizard I 

Graphical City Selection for Online Reservation Booking 1 

Incoiporation of Government PerDiem Data into Travel Rules Enforcement 2 

Enforcement of Travel Policy during Booking 5 

Incoiporation of Carrier Direct fares with Data from GDS/CRS 8 

In Browser Support from Travel Agent in Online Booking 1 1 

Integration of Multiple Travel Data sources into an Expense Management system 1 1 

Audit system for EFT payments fix>m a Expense Management Systwn « 12 

Business Workflow for Requests and Approvals 1 7 

Booldng Management Process 19 

Graphical City Selection for Online Reservation Booldng 

Selection of cities from a map used as input into a GDS (aka, online reservation 
system) for the retrieval of actual Flight Schedules/Fares, Hotel Availabilify/Rates, 
Car Availability/Rates, Reserviag, and Booking a trip. This allows the system to 
accept the travel cities, and uses that data to lun a real-time query against the GDS to 
retrieve Air/Hotet/Car availability, and once the user has made a selection, a 
fg^ reservation will be created. 

H Unique features: 

o Traveler selects cities- not auports- the Outtask system looks c?) the 

tH correct airport or region code to supply to the GDS. This makes travel 

IjJ planning easier, eliminates errors, and allows Outtask to extend the 

g availability search to include all airports in a region. 

0 Smart de&ultingofpersonal and corporate preferred airports. This allows 
a company to specify that a particular HOME airport always be included in 
the search - in a multi-airport city this can force unpopular but cost 
effective departure airports to be included. 

o Smart defaulting ofpersonal and corporate preferred airlincs/hotels/cais. 
This allows a company to specify that a particular carrier will always be 
included in the search - this feature is particulariy useful for con^>arues 
that have volume contracts with a particular carrier. Combined with our 
preferred carrier rules enforcement it will allow a company to enforce 
strict control over employee travel on non-prefcned carriers. 
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Incorporation of Government PerDiem Data Into Travel Rules 
Enforcement 
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This is provided under the rules policy enforcement in the Outtask Travel system. It 
will cither warn the user of an ind&action, or require approval before the booking can 
proceed. Hiis feature woiics as follows for hotel rates: 

" US Oovenuneat per-diem rates are dectiomcally loaded into Outtask 

■ PerDiem users are infonned vAen they attempt to reserve a hotel that exceeds 
the PerDiem latt for that locality 

■ When Ae PerDiem poUcy is in effect one of the following happen when a 
hotel rate exceeds the amount for that location. 

o Warning -Hie user will be required to enter a reason for the out of policy 
reservation, the user's manager will be informed, and the booking will 
proceed. 

. 0 Approval Required -The user will be required to enter a reason for the 
out of policy reservation, the reservation will be cancelled unless the user's 
manager approves the request 
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Enforcement of Travel Policy during Booking 

Designation and enforcement of coiporate travel policy when the user b in tbe 
booking process - as the user Selects a Flight, Hotel, or Car that is disallowed under 
company policy 1) the user is notified, and 2) it will not be aUowed to go to ticketing 
until approval. In existing systems, travel rules enforcement occurs after the 
employee has performed the booking by the Travel agent - Outtask's system is much 
unproved over these systems- it alerts the employee at the time of the rule infraction 
and presents acceptable alternatives to avert out of policy travel 
Unique features: 
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On a per lule basis, the employee's manager can be notified and the 
tickedng allowed to continue, or ticketing wiU be blocked until the 
manager approves the trip itinerary. 

When a user chooses a flight/car/hotel that is more expensive than a travel 
rule allows, a message will be generated for manager notification/approval 
that will include the lower cost options that the traveler decided not to 
take, and a message from the employee explaining the reason. This 
information will be included in both an email message to the manager, and 
the system log. 

Green / Yellow / Red coding of Air Fare, Car Rates and Hotel Rates 
indicating - Within Company Policy, Allowable but Requires Manager 
Notification^ and Out of company policy - will require approval prior to 
ticketing. 

All rules are computed based on &e NET ticket price; tins includes both 
the Front-end and Backend ticket prices. 

Configurable rules for Air/Hotel/Car in the following form: 

■ Approval/Notification if rate is $X above the best fare found 

■ Approval/Notification if rate exceeds SX maximum allowable by 
company policy 

■ Approval/Notification for airfere/car/hotel on non-preferred carrier 

■ Approval/Notification for airfare/rate on non-preferred carrier 
whwe preferred carrier is within $X of the non-preferred fere 
Approval/notification on a non-preferred carrier between 2 cities 
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Incorporation of Carrier Direct fares with Data from GDS/CRS 

This feature of the Outtask online travel system allows outtask to offer customers 
fares from both a GDS (Global Distribution System) and Internet Direct feres. 
Merged into a single user interfece for fare selection. 



Key aspects of this integration 

• Combiiiing GDS data with Internet direct feres provides user a smgle place to 
comparison shop the entire internet 

■ Interact Direct fares are filtered based on customer travel policy - this allows 
only showing internet direct fares that are a substantial savings 

■ User is notified as to the policy compliance of any fare at the time of purchase 
regardless of its source (GDS or Internet). 

• The system performs buy tracking to c^ture internet booldngs and integiale 
this data back into the Travel Reporting system. 

Key Technical Aspects 

■ Combined presentation of feres firom multiple providers 
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" Filtering out Internet direct fares based on company policy 
■ Ci^turing the BUY event so that reporting can take place. 

> User is asked to verify the itinerary tibat the BUY traddng detects as bong 

correct 
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In Browser Support from Travel Agent In Online Booking 

This feature allows the user of the Outtask Online booking system to contact alwvel 
agent or customer support engineer for help wi4 Online booking. Using this system, 
the user can contact a Travel Agent or CSR in the following ways: 

■ Voice OvCT IP Phone conversation 
• Shared Browsing session 

■ The Voice over IP support allows a user to click on a link, and talk to a Travel 
agent for Immediate support during the booking process* This allows a 
Traveler to make reservations w/o requiring an agent to be involved, but 
provides the utaity of an immediately available. If the traveler has progressed 
to the point of having a reservation in the system the travel agent is able to 
retrieve the reservation for review or modification while the customa is 
online, 

^ ■ Shared browsing support aUows a user to enter an interactive chat dialog with 

Q a CSR while the user is m the process of booking. This fecility allows a CSR 

U to posh screens to the user to assist ittihe booking process. 

W 

W 

g Integration of Multiple Travel Data sources into an 
, Expense Management system 

O 

TJe Outtask &q)ense Management system, ViaNet. integrates Credit Card data feeds 
g ofchargemfonnation into the Expense Rqwrt creation process. 

J* These features of the system do the following: 

■ Incorporate Post Booking infonnationimo the Expense Manager 
combmed with other data sources to fbnn an expense record. 

• Manage the *lUcdpt« data electronically, fieeingu^ 

remitting paper receipts to support paperiess expense management 

■ Allow the wireless entry oftTttveletsei^cnscs into stagmg area for exoen^ 
reporting *^ 

Post Booking Information 

•me incoijwration of Post-Booking information into the Expense Management System 
allows aU data that presented in a Travelers Itinerary to be incorporated into an 
expense report The key technology issue is the ability to tie a data record to the 
appropriate user. Once competed, the post booking data is used to complete an 
expense record. This record includes the following infomiation; Tmvel Dates, vendor 
amount, d^aiture/arrival. carrier, taxes, and record specific infomiation such as ticket 
number. Other available data sources MAY be coirelated to this reooixl to add to the 
datarecord. For instance, a Post Ticketing rental car ejqjense record wiD contam 
travel days, and vendor information, but not final cost This system wiU correlate the 
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post ticketing record with a credit card charge record, and coniplete the rental car 
expense record 



Electronic Receipt Management <- Paper less expense reporting 

T\m feature alleviates the user from having to turn in receipts for items that can be 
cq)tured and tracked electronically. This feature combined with user authentication at 
submission time to verify the identity of the user submitting the expense will enable 
paper-less expense report management The "electonic" record of the expense item is 
maintained in an un-alterable form associated with the expense. When the company 
needs to review the receipt, it is accessed via a web browser. 

Wireless Device Expense Collection 

A user can enter a record of an tsxptosc from a Wireless device. This record will be 
available for use the next time a user completes an expense report The following 
information is transmitted; Expense Type, Amount, Date, Project, and a comment 
Once stored as an expense record the user simply clicks the expense into the expense 
report This feature should be distinguished from that of filling out an expense report 
Q using a wfreless device, and submitting it We believe that this is a much more user 

\ff friendly approach to capturing the expense at the time it occurs, and then 

IV incorporating it into an expense report when auser has access to acomputer. 

« 

g Audit system for EFT payments from a Expense 
, Management System 

0 Id the T&E system we manage electronic fonds transfer payments for many of our 
customers. We process milUonsofdollars a day in funds payments. Thesheer 

Q volume of the transfers is so large that there is no economical way to manually audit 

the transfers to see whether any defects in the system led to problems with the files. 
Malfunctions in die payment subsystem arc costly as once the payment is made and 
the money transferred it is difficult to undo any errors. Additionally there is no 
economical way to manually detect whether there is anything out of the ordinary with 
the files of one of our customers that would indicate that they made errors v^en 
releasing reports or if someone managed to find a way within the system to get a large 
report approved that should not have beea 

With this invention we analyze the transfer amounts themselves statistically to sec 
w^iether they fell outside the norms of the transfers for that company. We also 
analyze the individual expense reports that are being paid to see if the r^ was not 
approved v*en typically that traveler's reports require approval We check die total 
amount paid to each traveler to see if any tiavcler*5 reimbursement total is above a 
threshold. We also check the age of therqjort to sec if it was m the past for enough 
to it was possibly abeady paid. TTiis way we can investigate to prevent accidental 
double-payment due to system znalfiinctioa 

The audit system generates reports in HTML fonnat daily. These reports are sent to 
appropriate administrators for review and can optionally be sent to Outiask customers. 
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The parameters for the audit system can be configured on a company by company 
basis. 



The audit report is generated after the EFT files are generated and before they are 
transmitted (the transmission is manual for security reasons). Our staff has the ability 
to act on any issues raised by the audit report prior to sending the files. This audit 
system has allowed us to be proactive and contact customers with suspected issues 
before their administrators have discovered them. 

The architecture of the auditing system has an extensible architecture to support 
customer specific business process audit rules. The business rule has to be cjqwess- 
able in tem^ of on data dements contained in the EFT, previous reports from that 
company, or the previous transfers fiom that company. 

Audit Example: 

10/02/2002: Results of ranoing audit procedures: 

s\ 

0 

w 
a 
I* 

■ 

caah 

c? 

{n Total batch paynent is highic than avtrage 

0 

tl C«ah 
52507 

1084B.14 

Total payaents for this etoploytta oxcaads lOOOO 



Cash 
032033 

20330912nhc473< 
599.46 

Report vas automatically approved 
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44S831.41 

Total batch payaent la higher than average 



Cash 
34004 

4OO40822dTlOO4S 
117.3 

RaporC waa automatically approved 



CC 

102034 

2034092711V13499 
469. 7& 

Mport waa autooaticaUy appzovad 



Cash 



£999.86 

Total batch payment is higher than average 



241824.5^ 

Total batch payosnt is higher than avaragt 



Cash 
4425.26 

Total batch payment la higher than average 



Caah 



9439.99 

Total batch payment la higher than average 



10/02/2001: VinPayer did not create any payments for following ciistomeni 



:o6060p H213 



6T60604 1193 




Ml 



rRfiHOTE-BILXiJlKS- 



E 



l-PREBOTE-BILUHG- 




ff::A3H^PREH0TE- BILLING 



fcA5H-PREirOTE-BrLLrNC- 



0l:l8i46(28) 



216 



RAG60112 



RSP3a522 191 



I)l;01il9<2a) 



a>PIieNOtB-&lU.IlIG- 



01:21:5S(19s 



H-PltEVOTE-BI LX.IH6- 



i-PREHOrc^aZUiIVG- 



208 



H-niEaKlTE-BILLlHG- 



01:21:36(58} 



01:01 ; 03 (2a > 
Dl:07:33(3s) 



01s 17; 32(1 



bSH-PREMOTS-BIU.IBG* 



01:07:21(49) 



SVG93007 |185 



TAKL0203 




^B'-PRPIOTE-BrLLrtlG 



01:05; 49 (83) 



hPAEvore-Bzuim;- 



01:27:46(4*) 



ASH-FRCNOTB-BXUISC- 



^SH-PRKNOTE-BILLING- 



ICI15220 1190 



Jl-PRENOre-BZUZNG- 



01:07:27(6*) 



0ljl4:00{83) 



01:07:17(14jH 



10/02/2001: Wtyer created payment files for following customen: 



Bank: MBA(ds) 

CC:NASTSR CARO 

Run tCASK-PICHOTE-BUUNG 



ACH flat 10020118 .MBA 



Batches/OetAls 

Debits 

Ccedits 



1/97 
0.00 

142423.29 



0/0 



0/0 



Billing: 
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CC: 

0/0 



Total: 

1/97 
0.00 

142423.29 



Bank: BOD(OS) 
CCtRone 

Ran : CASH-PRENOn-BIILIHG 



ACS fU] 10020126. BOD 
Q. Batdies/Detals 

w 
m 



Dtblts 
Cndits 



».00 



14. 

o 

0/0 *' 



ToUll 

2/7 

0.00 

2053.81 



Business Workflow for Requests and Approvals 

The invention is an object-oriented workflow framework designed to unify user 
requests across a heterogeneous environment The end users sec a single "Request 
Queue" tracking requests they have made, and a single "Approval" queue for requests 
from others that they must act upon even though the physical requests may reside on 
different systems. The intellectual property here is an object-oriented framewo^ 
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which is data independent that manages each of the requests through several stages, 
enforcing rules or other business logic. 

The idea of the single request and approval queue is not new to the Outtask system. 
From the perspective of the end user this functionality has been in the product since 
our initial release back in late 1 999. However that initial system was built specifically 
to handle manually inserted travel requests (not requests taken from a CRS feed), and 
while we had hoped that it would be easily extended to handle requests fiom other 
products it turned out not to be so. We began a redesign of the system fiom the 
ground up in June of 2000. Over fee next several months we deployed a partial 
instance of the invention that could handle HR requests in addition to the manually- 
inserted travel requests, but now we are preparing to roll out the final version which 
has been updated to read data firom a CRS system and has automatic rules 
enforcement built into it These last two pieces are key intellectual property for us as 
they represent how we have been able to mtegrate multiple CRS feeds into the 
Outtask system. 

This feature provides an object-oriented framework for workflow that exposed a 
single API for creating, promoting, rejecting, and fulfilling any request tiiat a user 
O could make. The framework is data independent so that the physical requests can lie 
W in different systems without any changes being made to the fi-amework. We have also 
Jg added object-oriented rules enforcement logic to this framework. The nature of this 
^ fiaraework is such that we can add or integrate other products mto the Outtask 
0 fimework quickly and easily. All we need to do is build the data access layer and 
1^]^ then our 0-0 framework takes over from there. Our developeis can mnxpulm any 
# type of request, be it a HR Leave request, a Travel request, or a request for an order of 
f L office supplies with the same high>level code. 

0 

I* The workflow siq)ported by the fi:amework is as follows: 

^ 1) Zero or more "preprocessing" steps. Preprocessing steps are those requited 

w* before the request would need to be approved. 

2) Zero or more "approval" steps, where a person (typically a manager) 
approves the request 

3) Zero or more "processing" steps. Processing steps are those required after 
approval but before the request can be fulfilled 

4) One or more "fulfillment" steps, where the request is actually fulfilled. 

Additionally a request can be rejected during the preprocessing, approval, and 
processing steps, and can be withdrawn by the requestor any time prior to fiilfiUment 

Some examples of this workflow: [MB: We have to decide whether the rules 
enforcement is part of preprocessing... after writing this I think it may be but wc could 
enforce rules wherever we wanted -Fred]. 

Travel. In the preprocessing steps the traveler goes online or calls a travel 
agent arid makes a reservation in the system. Hie automated rules system receives the 
reservation from the CRS and determines whether this specific request requires 
approval (and if so by whom) or if the request meets policy guidelines. If die request 
requires approval it is routed to one or more people or alternatively one or more 
queues where groups of people can approve the request before it proceeds to 
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processing and fulfillment If the request does not reijuire approval it proceeds 
straight to processing and fulfilhnent During the processing phase the agent confirms 
the reservation and the credit card is chaiged. If the credit canl charge is accqpted by 
the credit card company the request is fulfilled by the issuing of the ticket 

Human Resources Leave Request After the request has been entered, there is 
no preprocessing required. The automated rules system examines the request and 
company policy to determine wither this specific request requires £q>provaJ (and if so 
by whom). If the request is approved, or if the request did not require approval, then 
the request proceeds to fulfillment, where the employee's leave bank is decremented 
by the amount of the request 

In either case, had the api^over rejected the request h would have been sent 
back to the requestor who would have had the opportunity to comm^ fui&er on the 
request and resubmit it, or withdraw the request h the travel case» the travel agent 
could reject the request during processmg if the reservation made during the 
preprocessing phase had expired and no equivalent reservation could be made. The 
agent could also have rejected during preprocessing if no reservation could be miH^ 
^ that met the traveler's criteria and company policies. 

y 
ru 

g Booking Management Process 

j^k This system employs a set of configurable rules/business processes diat allow agents 

. to segregate travel requests booked throu^ the Outtaak Travel System based on 

fik priority/in^rtance on a set of factors. Based on the segregation, special attrition can 

O be paid to certain types of requests. The a sample ofthe rules used to classify 

H resenrations for special handfing include the following configurable factors* 

P ■ Travelers marked as VIP by the travel agency (e.g.CEO/CCK),t^^^ 

^ high priority handling. Routed to special queues m the GDS for personal caro 

Trips with expensive tickets that meet certain reqmts (e.g. Satmxiay night 
slay): high priority handling. Tickets like this can be ideal candidates for 
agents to seek fee waiver requests. If I have a $2000 ticket Fm buying 4 days 
before I leave, and it has a Saturday night stay, it might be worthv^diile for the 
agent to get me a 3-weck advance waiver, dropping the ticket to S800 + (let's 
say) a $400 fee charged by the agent Saves the traveler's company $800, 
makes us $400. 

Tickets for travel in next N days: agents are much more aggressive on getting 
these issued, lets say. . 

Travelers taking trips on airlines on which they have status: high priority 
handling. If a United 100,000 traveler has a trip on United, that trip is queued 
for priority handling regarding upgradesAvaivers/whatever. 
Fare expiration rules: trips can be evaluated for how soon until the fare 
expires, and routed/re-routed based on that infoimation. In other words, a fiie 
good for another 10 days can go on a low priority queue. If it's still sitting 
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* 



there 7 days later (which it probably shouldn't be), it gets bumped to a hiidier 
pnonty queue. ^ ^ 

This system has the following primary components: 

■ Passenger profile data store- for maimging passenger attributes used 1^ 
classification - this is independent of the user's travel preferences etc ~ this is 
where special attribution is added by a travel agent to designate VIP status etc. 

■ Rules driven system to extract trip data from the CDS, evaluate rules to 
classify and re-assign itineraries to special GSD Queues for appropriate 
handling. 

• Web based mtcrface for agency for classification rules and profile 
management 
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